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Abstract 


This paper discusses the development of the PowerPC hardware reference platform (HRP). The HRP is a 
system design architecture that allows a PowerPC-based computer designed to that architecture to run 
operating systems from Apple Computer, IBM, Motorola, and others. The goal of the HRP is to let 
customers choose computer hardware independently of choosing the software they will run on it. 


The paper provides insights into the history, rationale, and design issues facing the developers of the HRP 
architecture and its compliant hardware. It does not present the architecture or hardware design in detail, 
because that information will be made available in other documentation. 


Introduction 


The PowerPC family of microprocessors, which is being jointly developed by Apple, IBM, and Motorola, 
is the foundation for an established and rapidly expanding market for RISC-based hardware and software. 
Apple Computer has shipped well over one million Power Macintosh™ computers since introducing them 
in March 1994. Companies such as Daystar, Pioneer, Power Computing, and Radius have also announced 
Power Macintosh compatible systems. IBM intends to make major hardware and software product 
announcements for a full line of PowerPC systems, complementing its successful PowerPC-based 
workstation and server products. Motorola has recently introduced a broad range of desktop and server 
systems. Other companies such as Bull, Canon, and FirePower have announced or shipped PowerPC- 
based systems. PowerPC-based computers today outsell all other RISC-based computers combined. 


The PowerPC systems shipped by Apple retain many legacy characteristics of Macintosh™ hardware and 
software. The PowerPC systems shipped by IBM, Motorola, and others provide the benefits of the 
PowerPC architecture yet retain many legacy characteristics of Intel-based PC designs. Applications have 
been written for both environments. However, the operating systems on which the applications run are not 
compatible with the other type of hardware platform. This forces computer users to choose among 
incompatible hardware configurations, instead of focusing on what applications they need to solve their 
problems. 


This incompatibility also causes hardware manufacturers and software developers to have to choose 
platform families. Thus, PowerPC-based development is fragmented, and availability of hardware and 
software is inhibited, limiting the options available to users. 


To correct these problems facing customers and developers, Apple, IBM, and Motorola looked at various 
ways of combining the two hardware architectures into a common system architecture. In November 1994, 
the three companies announced agreement to develop a common hardware architecture that supports 
operating systems ported to the PowerPC family of processors. With the introduction of systems based on 
the new architecture, software vendors can anticipate a large, compatible hardware base and are motivated 
to create or modify their code for PowerPC processors. 
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The three companies agreed to create a hardware reference platform (HRP) specification. The 
specification defines an architecture that describes the hardware and firmware interfaces which a 
compliant platform must make visible to software. The specification emphasizes the programming model 
of a compliant system. As an architecture, it is precise enough to assure software compatibility for several 
operating environments, broad enough to cover a range of systems from portables through servers, and 
flexible enough to evolve with technology and market demands. The specification will be released to the 
industry in the near future. 


Under the initial HRP agreement, Apple is responsible for porting Mac OS to the HRP, IBM is responsible 
for porting AIX™ and OS/2™ for PowerPC, and Motorola is responsible for porting Windows NT™. 
Sunsoft and Novell have announced plans to port Solaris™ and Netware™ as well. The goal is to port 
these operating systems to run in native binary form on any platform that conforms to the HRP 
architecture. Additionally, the HRP architecture is designed to allow applications that run today on these 
operating systems to run unchanged from their existing code. 


The three companies also agreed to develop an initial hardware implementation to facilitate the 
development of other compliant systems and to encourage an industry infrastructure that will offer widely 
available components and subsystems for computers built to the architecture. 


A prime objective of the HRP specification and its initial hardware implementation is to create an 
environment that lets other chip and system vendors build components and HRP systems rapidly and 
inexpensively. Whenever possible, industry-standard, commodity-priced components and subsystems are 
used or encouraged. Where unique function or partitioning is not readily available, Apple, IBM, and 
Motorola are collectively providing major ASICs for this implementation. The companies plan to produce 
specifications for these chips that will be made available to the merchant market. Note that an HRP- 
compliant system does not have to use these chips. 


The specific initial implementation from Apple, IBM, and Motorola is described later in this paper. The 
final version of this design, as well as the HRP architecture itself, may have different characteristics, since 
it is still under development. It is expected that other compliant systems will be produced by Apple, IBM, 
Motorola, or other partners. 


Current Product Environment 


To gain an even broader acceptance of PowerPC-based designs among hardware vendors, software 
vendors, and system users, Apple, IBM, and Motorola have a strong desire to make it easy to run multiple, 
binary compatible operating systems on PowerPC platforms, particularly in the personal computing 
desktop marketplace. The companies originally took different approaches to accomplishing this common 
goal. 


On one hand, IBM’s personal computing customer base was served by machines built around the Intel 
processor architecture. IBM wanted a new architecture to exploit the capabilities of the PowerPC 
processor in order to expand solutions for customers. This architecture was designed to coexist with Intel- 
based PC’s. To achieve this, IBM created an open industry standard for PowerPC-based systems. This 
standard, called the PowerPC Reference Platform™, provided new levels of performance and function in 
the PC marketplace while utilizing the existing PC industry infrastructure for low-cost, high volume 
components and subsystems. 


On the other hand, Apple’s customer base used machines built around Motorola’s 68000 processor 


architecture. Since PowerPC would replace the 68000 as Motorola’s flagship processor architecture, 
Apple’s first priority was to provide its customers with a seamless transition to the PowerPC architecture. 
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The next sections give an overview of the two pertinent hardware architectures currently in the PowerPC 
desktop marketplace, namely the PowerPC Reference Platform and the Power Macintosh. They are 
described here to give historical background to the new HRP. 


The PowerPC Reference Platform 


The PowerPC Reference Platform Specification version 1.1 released in October 1994 is an open 
specification for building PowerPC-based computer systems. It is sponsored by IBM, Motorola, and other 
companies. There are two important aspects of this specification. First, the specification provides a 
description of the devices, interfaces, and data formats required to design and build a compliant computer 
system. It describes methods to abstract hardware details from operating system software. Multiple 
operating systems can then run on a compliant platform. 


Second, the specification provides a reference implementation that describes in detail the design of a 
compliant system, to encourage other system vendors to build and market PowerPC-based systems. A 
reference implementation is a fully disclosed design with known operating system support. Reference 
implementations allow vendors to build hardware-compatible systems while operating systems move to a 
hardware abstraction model. The reference implementation described in the October 1994 specification 
runs ported versions of AIX, OS/2 for PowerPC, Solaris, and Windows NT. 


The processor complex in the PowerPC Reference Platform consists of the following: 

e A PowerPC processor 

e A local bus upgrade socket which accommodates an external cache card, a processor upgrade, or a 
combination of the two. 

e The PCI bridge/memory controller that supports big-endian and little-endian operations. 

e System Memory 

e Boot ROM 


The I/O complex supports PCI and ISA devices and consists of: 

e 2PCTI slots (one used for graphics) 

e 3 ISA slots 

e A PCI-attached SCSI controller. However, the architecture does not mandate the use of SCSI or a 
particular SCSI controller. 

e An [O subsystem consisting of an industry-standard PCI-to-ISA bridge (System I/O) and a Super I/O 
chip (which provides many of the typical PC I/O functions). Again, the particular selection of chips is 
not mandated. 

e Business audio subsystem. As above, the particular chip is not mandated, but an audio function is. 


An important feature of this design is that except for devices attached to the processor local bus, the 
system uses PC industry-standard components. It was a goal of the specification to leverage PC industry 
standard devices where appropriate. This allows support for devices and peripherals widely used in the 
marketplace, and takes advantage of the declining cost for these components driven by PC volumes. 


IBM intends to announce a complete family of PowerPC-based systems that use the PowerPC Reference 
Platform architecture. Because that architecture allows flexibility in hardware design, these systems will 


have different implementation characteristics but will run the ported versions of AIX, OS/2 for PowerPC, 
Solaris, and Windows NT, as well as Intel x86 code (using software emulation technology). 


Power Macintosh 


In March 1994, Apple started using the PowerPC microprocessor in its Macintosh family of desktop 
computers, replacing the Motorola 68000 series of processors. Built-in emulation software lets programs 
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compiled to the 68LC040 instruction set continue to run in the PowerPC environment. The first 
generation of Power Macintosh products use a version of the PowerPC bus (called the Apple RISC bus, or 
ARBus) to connect built-in I/O devices and use the NuBus™ to connect plug-in expansion cards. Several 
configurations have been introduced with PowerPC 601 and 603 processors running at speeds up to 120 
MHz. These computers run a PowerPC version of Mac OS operating system, with provision for both 
software emulation and hardware coprocessing to run software compiled to the instruction set of the Intel 
x86 family of processors. 


The second generation of Power Macintosh desktop products, planned to be introduced this summer, use 
the Peripheral Component Interconnect (PCI) bus to connect both internal I/O ASICs and expansion 
cards. They also include built-in firmware, called Open Firmware, that implements IEEE Standard 1275 
for Boot (Initialization, Configuration) Firmware. They include PowerPC 601, 603, and 604 processors 
and continue to support both Mac OS and software compiled to the Intel x86 environment. 


The second generation Power Macintosh products include these general features: 

e Use of the PowerPC family for main system processing. Motorola’s 68LC040 is supported through a 
built-in emulation system. Specific configurations may also include x86-based processors to support 
DOS and Windows™ applications. 

e Use of the PCI bus to support all I/O and system expansion. Other buses (such as NuBus, SCSI, and 
IDE) are implemented by means of bridge ASICs connected to the PCI bus. 

e System startup through Open Firmware. While Mac OS continues to be the principal operating 
system for Power Macintosh, Open Firmware lets other operating systems that are ported to the 
PowerPC take control of the computer. Open Firmware also allows PCI expansion cards made for 
traditional PCs to function in Power Macintosh computers. 

e Processor bus coherency. Memory systems connected directly to the PowerPC bus, including main 
RAM and all levels of cache, belong to a single coherency domain. 

e Support for both big-endian and little-endian addressing. Besides the support for both modes built 
into the PowerPC processor, storage subsystems such as frame buffers are accessible through both big- 
endian and little-endian apertures. 

e Support for native interrupts and native device drivers. 


The New Hardware Reference Platform 


The HRP is a new, unique architecture that combines elements of both the PowerPC Reference Platform 
architecture and the Power Macintosh architecture. It is a system design architecture that allows hardware 
developers to build computers that will run ported versions of AIX, Mac OS, Netware, OS/2 for PowerPC, 
Solaris, and Windows NT. These are referred to as the six native operating systems. As they do today, 
DOS/Windows programs written in Intel x86 code can also run on these systems through emulation or 
hardware coprocessing. 


As an architecture it defines the hardware and firmware interfaces, data formats, and minimum 
functionality that software expects to see in a hardware implementation. With this information, a third 
party can design a computer that performs the same functions and runs the same system software and 
applications as a machine produced by Apple, IBM, or Motorola. The discussion for the rest of this paper 
will focus on both the HRP architecture and an initial, or reference, implementation of it currently being 
developed by Apple, IBM, and Motorola. 


An implementation of this architecture must provide for the address maps and register mappings and 
definitions required by all operating systems that run on that HRP system. It should also support as much 


common I/O equipment as possible, consistent with cost and size targets for the system. 


One of the goals of the developers of the HRP was to minimize the trauma to the various operating 
systems of having to support new functions from other environments. Several cases had to be considered: 
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e Unique architectural features: a company had a function unique to its native environment (Power 
Macintosh or PowerPC Reference Platform). For example, the Apple Desktop Bus (ADB) is unique to 
the Power Macintosh environment, while the 8042 keyboard interface is used in the PC environment. 

e Implementation: a company had its own implementation of a common function, such as audio. 

e Growth and evolution: all companies agreed to extend HRP to include new or better functions or 
implementations of functions. 


In the first case, deciding whether to include a function in the HRP architecture was based on whether its 
function would be useful in the HRP environment. That is, would customers still expect or want it? This 
was particularly true in the I/O area, where, for example, there are different mouse/keyboard and different 
serial port architectures between the original PowerPC Reference Platform and Power Macintosh. Also, 
PowerPC Reference Platform systems support plug-in ISA adapters, which do not exist in the Power 
Macintosh architecture. To provide broad compatibility, the HRP architecture specifies a minimum set of 
required functions that supports key features from both environments. In the case of I/O, this means an 
HRP platform will support I/O from both the Power Macintosh and the original PowerPC Reference 
Platform environments. 


In the second case, factors such as projected market requirements and product cost helped decide which 
implementation of a function to include in the initial HRP system design. Examples of common functions 
for which implementation decisions had to be made include the audio subsystem, the storage subsystem 
(hard disk, floppy, CD-ROM), and the graphics subsystem. The HRP architecture generally does not 
mandate which particular implementation of a subsystem is required, but it does provide mechanisms to 
maximize compatibility. For example, IDE or SCSI interfaces are both acceptable for hard disk and CD- 
ROM, and Open Firmware and device drivers will make them compatible in an HRP system. An 
implementation decision was usually based on the total effort, both hardware and software, required to 
develop and build a particular implementation. Thus, all other factors being equal, an implementation was 
chosen to minimize the porting effort of the majority of operating systems that are planned to run on the 
HRP. That porting effort usually consists of writing new device drivers. 


In the third case, architecture decisions will be based on market requirements and industry standards and 
trends. Implementation decisions will also consider schedule and cost. As technology and market 
requirements evolve over time, the HRP can change to include these new functions. For example, new 
infra-red (IR) technology for wireless communication or new serial bus standards can be added to the 
HRP. Emerging multimedia standards are another example. 


It should be noted that the inclusion of the PCI bus architecture in the second-generation Power 
Macintosh computers was a big step in helping Apple, IBM, and Motorola complete the definition of a 
common architecture and implementation. The current HRP architecture specifies PCI headers for various 
functions in an HRP system and could someday be updated to include other bus architectures. The 
architecture defines how operating systems are informed of the presence of other bus interfaces. 


The HRP architecture also specifies the use of the IEEE Standard 1275 for Open Firmware, a technology 
that makes the computer’s hardware configuration process independent of any operating system. The role 
of Open Firmware in the HRP environment is discussed later in this article. 

The HRP architecture specification is meant to be an open, industry-standard architecture that will 


facilitate the rapid growth of PowerPC-based hardware and software. 


What the HRP offers users 


The HRP offers computer users a much more flexible operating environment. They can now buy a 
computer based on the problems they want to solve, not based on the computer’s hardware architecture. 


Page 5 May 8, 1995 


The creators of the HRP believe that software, from power-on self-test (POST) and diagnostics to 
operating systems and applications, drives the usability and acceptance of a computer system. A computer 
user judges a computer system by its user environment, responsiveness, functionality, and reliability. 
System software controls these attributes by leveraging the hardware features and performance to provide 
a total system solution. 


All the native operating systems ported to the HRP provide users with their traditional strengths and 
features. On a single hardware platform a user can now experience superior ease of use and installation of 
hardware and software, install many industry-standard applications and hardware adapters, and enjoy 
enhanced networking options. 


A customer can buy an HRP platform and preserve his or her investment in I/O peripherals such as 
keyboards, displays, printers, telecommunications, etc. As the industry standardizes on HRP, customers 
will have a wider choice of peripherals and connectivity options. 


A fundamental goal of the HRP specification is that existing applications that run today on Power 
Macintosh and PowerPC Reference Platform systems will run unchanged on an HRP platform. Thus, the 
customer’s software investment is also preserved. 


Initial HRP Implementation 


This section presents a description of the hardware elements in the initial implementation of the HRP. 
Note that this is only one example of a system design that complies with the HRP architecture. It is not a 
definition of the architecture, and other implementations may be significantly different. The design of the 
initial implementation is still under development and can change from that described here. 


Detailed information on the initial hardware design will be released by the three companies at a later date. 
The first customer shipments of compliant hardware are planned to be made in the second half of 1996. 


A block diagram of the initial system is shown in Figure 1 on page 8 . 


Processor 


The processor is a PowerPC microprocessor. In this implementation it will be the latest model of the 
PowerPC 604. It has a 32-bit address bus, providing addressability up to 4 GB. It has a 64-bit data bus. 


System memory (DRAM) 


Minimum memory size is 8 MB. Design options are being explored to try to achieve a maximum memory 
size of 1 GB. 3.3 volt asynchronous DRAMs are planned to be used. The data path is 64 bits with either 8 
bits of parity, or ECC, or no protection. 


Level 2 (L2) cache 


This implementation supports up to a 1 MB of L2 cache. It has a 64-bit data path with optional 8-bit 
parity, attached to the processor bus in a “lookaside” configuration. “Lookaside” means that both the L2 
cache and the memory controller decode CPU addresses in parallel. The L2 cache can be used in either a 
write-through or copy-back mode. 


Industry standard cache memory chips will be used. Initial versions of the HRP reference implementation 
will use asynchronous SRAM. Other versions can use burst SRAM for higher performance. 


The L2 data and tag SRAMs will be on a card, mounted on a 182-pin ELF connector to simplify upgrades. 
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The card supports both 5 V and 3.3 V components. The motherboard contains 5 V-tolerant 3.3 V buffers 
for the data SRAM outputs. The tag SRAMs have 3.3 V drivers. The card will also contain an EEPROM 
with a serial interface, which will contain presence-detect and other L2 configuration information. 


Read-Only Memory (ROM) 


The HRP architecture specifies a region for ROM address space. In the initial implementation it is located 
in the top 16 MB of the 4 GB address space. 


The OS ROM is an optional, socketable ROM which is present if the system runs Mac OS. It is 64 bits 
wide and up to 4 MB in size. 


The system ROM contains initial boot code, Power-On Self-Test (POST) code, system Open Firmware 
code, diagnostics, and other code unique to the hardware configuration in the system. It is 8 bits wide and 
up to | MB in size. It is implemented using Flash ROM. 


Both ROMs are addressed in the top 16 MB of the 4 GB address space. The ROMs do not support parity 
or ECC. They are currently 5 V parts, and the use of 3.3 V parts is being investigated. 


Memory Controller and PCI bridge 


The memory controller and PCI bridge chip in the initial implementation is a follow-on to an existing 

Motorola part, MPC105 Eagle. This chip is the interface between the processor bus and the PCI bus and is 

also the controller for the memory, second level cache (L2), and ROM (processor bus). The processor bus 

interface is 64 data bits and 32 address bits. The PCI interface is 32 data/address bits. PCI bus speeds of 

up to 33 MHz are supported. The chip uses 3.3 volts. The new functions this ASIC supports for the HRP 

include: 

e Anew address map compliant with the HRP architecture. Some legacy address maps from previous 
architectures may be supported to allow software time to migrate. 

e ECC for system memory (DRAM). Controls and checking/generation for a SEC/DED code are 
provided on the chip. 

e ROM controls to handle the two types of ROM present in this implementation. 

e Miscellaneous other functional enhancements. 
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Figure 1. HRP Initial Implementation Block Diagram 
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VO subsystem 

As discussed above, an important goal of the HRP is to support I/O peripherals from both the Power 
Macintosh environment and the PowerPC Reference Platform environment. This section will discuss some 
of the hardware and software implications of this goal. 


PCI devices 


The PCI bus is the backbone of the I/O subsystem. There is one PCI bus in the initial implementation. It is 
compliant with Revision 2.1 of the PCI Standard. 


The following functions are connected to the PCI bus: 


Graphics subsystem. This implementation has a 64-bit DRAM-based graphics accelerator chip with 
at least 2 MB of EDO DRAM, which provides high resolution true color and multimedia capabilities. 
It has a bi-endian frame buffer, controlled by aperture addresses. The chip is a commercially available 
part and is mounted on the motherboard. In general, an HRP-compliant platform need only ensure 
that the graphics subsystem support several standard pixel formats and dual-aperture mode for bi- 
endian operations. 

Ethernet. The initial implementation uses a commercially available PCI bus-master Ethernet 
controller that is mounted on the motherboard. 

Two or three PCI expansion card slots. 

System I/O chip. This chip is mounted on the motherboard and contains general I/O functions. 
Although the initial implementation supports these functions, not all of them are required by the HRP 
architecture: 

e Up to 33 MHz PCI bus interface that supports master and slave transactions. 

e PCI Arbiter for 6 PCI masters plus the CPU. 

e Bus master Enhanced IDE controller. This controller supports 2 IDE channels (primary and 
secondary), and supports up to 4 devices (2 per channel). The controller has PCI bus master 
capability with scatter/gather functions. It also supports PIO modes 0-4 and DMA modes 0- 
2. Any operating system that runs on an HRP platform can boot from the IDE hard drive or 
CD-ROM. It is also capable of booting from the SCSI hard disk or CD-ROM. 

e PCI/ISA bridge, for 8- and 16-bit ISA devices. This bridge allows ISA mastering by 
forwarding ISA-master memory references to the PCI bus. 

e 7-channel DMA between ISA devices and PCI memory, compatible with an 8237 DMA 
controller. 32-bit DMA addresses are supported. 

e  16-channel (cascaded) 8259 interrupt controller function. This controls interrupts from 
timers and ISA devices. It can be configured with the MPIC interrupt controller logic on the 
System I/O-2 chip (see below) so that the combined interrupt structure is compatible with 
either Intel-based software (e.g. Windows) or Mac OS. 

e Timer (82C54) functions. 

e Miscellaneous decodes and support logic. 

System I/O-2 chip. This chip is mounted on the motherboard and provides the following functions, 
most of which are related to controlling I/O transfers associated with Mac OS environment. Although 
the initial implementation supports these functions, not all of them are required by the HRP 
architecture: 

e Up to 33 MHz PCI bus interface that supports master and slave transactions. 

e Controller for 5 Descriptor-Based DMA (DBDMA) channels. This function performs 
scatter/gather and process synchronization operations based on control words and a buffer 
list in main memory. 

e = Integrated 85C30 Serial Communications Controller (SCC) cell which supports GeoPort™ 
and LocalTalk™ operations. There are two SCC channels. Each is allocated one DBDMA 
channel for input and one for output. 

e Apple Desktop Bus (ADB) hardware interface. This is the interface to the Power Macintosh 
compatible keyboards, mice, tablets, and other ADB devices. 
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e Integrated Versatile Interface Adapter (VIA) cell. In this implementation of the HRP, the 
VIA cell is used for compatibility with earlier Macintosh interrupt processing. 

e Integrated SCSI-2 controller. One DBDMA channel is allocated. 

e Multiprocessor Interrupt Controller (MPIC) that supports 2 processors and up to 16 external 
and I/O interrupts. It can be configured with the 8259 interrupt controller logic on the 
System I/O chip so that the combined interrupt structure is compatible with either Intel- 
based (e.g. Windows) interrupt-handling software or Mac OS software. 

e Controller for a serial bus used to obtain internal system data for configuration and 
diagnostics firmware. 


ISA devices 


This initial HRP implementation contains an ISA subsystem to maintain compatibility with the many PC- 
style plug-in devices. The bus carries 16 bits of data, 24 bits of addressing, and provides for up to 3 ISA 
expansion slots. The System I/O chip described previously is the interface for the ISA subsystem to the 
PCI bus. The functions in the initial implementation provide the following services which are either 
required or supported by the HRP architecture: 


e Audio Subsystem. SoundBlaster™ compatibility is provided by a commercially available chip 
mounted on the motherboard. The system provides separate DMA channels for stereo recording and 
playback. 

e Power Management Chip. This chip is mounted on the motherboard and provides hardware control 
and interfaces to support the various system power-managed states, including hibernate and Mac OS 
SoftPower function. The chip is a microcontroller that responds to activities such as modem rings and 
mouse or keyboard signals. It provides power management interrupts and power supply control. The 
controller is powered by a separate 5 V auxiliary power supply which is powered on whenever AC is 
applied. 

e Super I/O Chip. In the initial implementation, this chip provides interfaces for: 

e Floppy Disk interface equivalent to the NS82077 controller. Auto-sense and auto-eject are 
supported for 1.44 MB (formatted) MFM drives. GCR disk format is not supported by the 
HRP architecture nor by this implementation. One ISA DMA channel is allocated for the 
floppy device. 
e Parallel Port. IEEE 1284 EPP and ECP are supported. One ISA DMA channel is allocated 
for the parallel port. 

2 serial ports, software-compatible with PC16550. The controller decodes COM ports 1-4. 

PC-compatible keyboard and mouse control is provided by Intel 8042-compliant logic. 

Real Time Clock (RTC) PC-compatible functions. 

Infra-red controller (IrDA, HP). 

e NVRAM, implemented as an 8K x 8 discrete chip. 

e 3 ISA slots. 


Open Firmware 


The HRP architecture requires all compliant systems to implement the Open Firmware startup process 
defined by IEEE 1275-1994 Standard for Boot (Initialization, Configuration) Firmware, and the PCI 
Binding to IEEE 1275-1994 specification. These standards evolved from the OpenBoot™ firmware 
architecture introduced by Sun Microsystems. 
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The Open Firmware startup process is driven by startup firmware, also called boot firmware, in system 
ROM and in ROM chips on expansion cards. While the startup firmware is running, the computer will 
power up and configure its hardware (including peripheral devices) independently of any operating 
system. The computer will then find an operating system on a mass storage device or in ROM, load it into 
system memory, and terminate the Open Firmware startup process by giving that operating system control 
of the PowerPC processor. The six native operating systems mentioned earlier are planned to run on an 
HRP compliant system with Open Firmware. 


The startup firmware includes these specific features: 

e It is written in the Forth language, as defined by IEEE Standard 1275. Firmware code is stored in an 
abbreviated representation called FCode. The computer’s startup firmware includes a loader and 
interpreter that will install FCode in system memory. Firmware in expansion card ROMs can modify 
the Open Firmware startup process by supplying device-specific FCode that the computer’s firmware 
loads and runs before launching an operating system. 

e The startup process creates a data structure of nodes called a device tree, in which the characteristics 
of the hardware system and of each peripheral device are described by property lists. The device tree 
is stored in system memory. The operating system that is ultimately installed and launched will 
search the device tree to determine the nature and characteristics of available hardware. The device 
tree can also store runtime drivers, written in the PowerPC instruction set, for various combinations 
of devices and operating systems. 

e System firmware includes a basic set of device drivers and associated resources such as fonts, written 
in FCode, that are required during system startup before an operating system is running. Plug-in 
expansion cards that are used during startup may also contain driver code. The firmware in system 
ROM installs these drivers in system memory so they can be executed on the PowerPC processor. 

e Firmware in system ROM may also contain debugging facilities for both FCode and some kinds of 
operating system code. 


Summary of Initial Hardware Design 


The initial implementation of the HRP architecture described here will support I/O devices and 
peripherals from both the Power Macintosh and the original PowerPC Reference Platform environments. 
Controllers and physical connectors are provided for devices from both environments. This allows 
operating systems to present their traditional user interfaces, while providing a path to eliminate the 
hardware incompatibilities between these environments that have existed in the past. 


The hardware partitioning and component selection for the initial implementation are based on today’s 
technology, industry standards, and cost-effective offerings from various chip companies including IBM, 
Apple, and Motorola. The partitioning and components will change as standards evolve and as technology 
and cost improve. For example, some systems may find it effective to build into the motherboard a chip 
that integrates PCI-attached Ethernet and SCSI functions. L2 controllers integrated on a chip with tag 
SRAMs could be used. At some point, perhaps the two System I/O chips will be merged. One or more 
other system functions could be put onto a System I/O chip. A faster or wider PCI bus could be used. 
Other IDE modes could be included. These are only some of the possibilities. 


The designers of this implementation believe they have met the HRP goal of creating a computer system 
that supports the six native operating systems and their applications. 
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Summary 


The HRP provides benefits for computer system customers, software vendors, and hardware vendors. It 
provides a common hardware and software design structure that allows customers to focus on the solution 
to their problems rather than on the architecture and features of a particular hardware platform. It 
preserves customers’ investments in applications that run on today’s PowerPC-based platforms, and lets 
them use many of their existing peripheral devices. 


The HRP will evolve to accommodate the latest industry standards, trends, and customer requirements. 
While the HRP architecture spans portable through server systems, the focus of the initial implementation 
is on the desktop market. The initial implementation provides a glimpse into the kinds of hardware issues 
being discussed by the designers of the HRP architecture. Apple, IBM, and Motorola will each produce 
other HRP-compliant systems that have company-specific added value but which will still run the same 
operating systems and applications. 


Apple, IBM, and Motorola intend to work with their partners to enable them to contribute to the HRP 
definition and build HRP systems. Companies interested in learning more should contact Apple, IBM, or 
Motorola. The three companies intend to release architecture, ASIC, and system specifications to the 
industry. This will reduce cost and prices over time as a large, commodity-priced infrastructure forms. In 
addition, they plan to work with operating system vendors and independent software vendors (ISV’s) to 
enable them to port their code to HRP platforms. 


Much thought has gone into designing the HRP architecture and its initial implementation. The HRP is 


planned to be the cornerstone for products from Apple, IBM, Motorola, and the rest of the PowerPC 
industry as the world of RISC-based computing grows. 
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